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PACKET 
STATUS 
REGISTER 


2006 Wrap-Up/2007 Warm-Up 


Well, the Dayton 
Hamvention and the 
DCC have come and 
gone, and we are heading 
into the winter doldrums 
for those of us in the 
northern hemisphere ... 


our BoD member Darryl 
Smith will remind us 


€ 


that things are starting 
to liven up down under, though, with spring 
coming to Oz! 

So, I am really here to tell you that things are in 
fact ramping up here in TAPRvania ... 

Dayton saw some exciting moments for us ... 


we met old friends and made new ones. 


We had a successful “Packet Bash”, but it also 
marked the last TAPR Bash. But the better 


news is that we have merged our gathering with 
that of AMSAT and we'll be hosting a joint 
gathering at Dayton 2007 - at the Air Force 
Museum on Friday night. Current plans call 

for a dinner in the vicinity of $30-35 and we'll 
have the run of the place before and after the 
dinner. I know that many of us are members of 
both organizations and will welcome the chance 
to get everyone together. Both groups will be 
changing the format of their dinners into a new 
format more suited to the new venture. We will, 
however, need to do this affair as a pre-paid 
event BEFORE we get to Dayton, as the logistics 
will be a little tighter for this soiree, so watch the 
PSR and other announcements for details. 


In September, we returned to Tucson for the 
DCC. We had many noteworthy founders of the 
organization present, and they were all invited to 
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say a little something after dinner. As I looked 
around the room, I could catch glimpses of tears 
of sadness for those who were no longer with us, 
as well as tears of laughter as folks poked fun at 
themselves and related many a tale of the trials 
and tribulations of projects gone by. The take 
home message from TAPR’s early days is that 
the developers of the TNC1 made a conscious 
decision to not make a personal or professional 
dime out of the organization, and it was that 
single watershed decision that has provided us 
with 25 years of viability and relevance to the 
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amateur community. While we marveled at their 
perseverance and sacrifice, we took aim at a 

new generation of projects, and announced our 
involvement with the HPSDR project. 


HPSDR stands for High Performance Software 
Defined Radio. It started out as a small group 
of individuals tinkering with ways to improve 
their SDR-1000 software defined HF radios. 
They designed a backplane (dubbed Atlas) and 
then two boards to act as high-performance 
replacements for the sound card in their PCs. 
(The sound card is the computer to radio 
interface for the software defined radio). These 
cards were dubbed Janus for the card handling 
A-D and D-A for the “sound” side of things, and 
Ozymandias (affectionately known as Ozy) to 
handle the radio keying/switching. 


The group and TAPR had initial discussions 
at Dayton, and we were excited to get involved. 
TAPR offered to act as facilitators for the project, 
or as I like to say, we offered to act as the glue to 
bring people and things together. The projects all 
remain under the control of the board designer/ 
builder, and TAPR acts as a general contractor. 
We handle the logistics of final board layout 
with the developer, although at this point, they 
had already done most of that and had working 
boards. We are moving to Alpha2 or Beta testing 
at this time, and will soon be ready to go into 
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production. Steve Bible is acting as primary 
liaison for TAPR, with Scott Cowling, a new 
BoD member providing us with his production 
expertise. Eric Ellison has been a big promoter 
of the HPSDR project from its inception, and he 
too has joined the BoD. Congratulations to both 
Scott and Eric on their election, and to John 
Koster on his re-election. 


The HPSDR list has about 400 members and is 
growing. When the developers are satisfied that 
the Beta run is satisfactory, then we'll proceed to 
production. Atlas is available now through TAPR 
as akit ... it will require some magnification 
and some soldering skill, but is doable as a kit. 
Janus and Ozy will be fully assembled AND 
tested boards with price to be announced. These 
boards are not something that can be easily built 
by everyone, so will not be offered as kits, but 
we may make a limited number of bare-boards 
available. We will not be providing parts if 
someone wants to “roll their own”. We will be 
asking buyers to pre-purchase the boards with 
a short lead-time. That is, they will be asked to 
pay in full to fund this project and we'll deliver 
tested boards within something like 4-5 weeks. 
This is the only way to get quantity discounts to 
hold costs down. With an established base of 
folks from the HPSDR list, we believe that we 


will have a large, ready-made base of purchasers. 


The costs of subsequent runs may not be as low 

in cost because of numbers - things are cheaper 
in quantity - so if folks are interested, they need 
to monitor the TAPR web site to try to get in on 
the first wave. 


Now, you may be asking yourself why anyone 
would go to the trouble of buying these boards 
just to talk to their SDR-1000, when a sound 
card or a USB or Firewire solution is available 
already? 


The HPSDR design is modular. Atlas allows 
us to add other boards to the system as they 
develop. There are already plans for receivers 
and transceivers, and a board to remove the 
dependence on an external computer. Please go 
to www.hpsdr.org for full descriptions of the 
proposed projects. Right now, we are committed 
to Atlas, Janus, Ozy, and Pinocchio (an extender 
card to allow you to debug and trouble shoot 
boards -this will be available as a kit like Atlas). 
As other developers make proposals, we will go 
through the process of vetting each project. The 
profits made on the card sales will go towards 
funding future projects in HPSDR and other 
projects. Discounts will be offered to TAPR 
members. AMSAT has donated development 
tools to project members, as well as financial 
support in the form of interest free loans to 
speed up development. In return, they hope to 
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see the development of widgets that will greatly 
improve ground-station performance. AMSAT 
has already a Software Defined Transponder for 
Eagle, its future Phase 3 satellite. 


Just as the TNC ushered in an unprecedented 
growth in digital communications, software 
defined radios will forever change the way we 
communicate, and our organization will stand 
ready to foster this new technology. We want to 
“free-up” the developers to develop, and accept 
the day-to-day concerns of production. We’re 
still trying to improve our skillset here, but the 
developers are being patient with us! 


John Ackermann has been working on the 
TAPR-OHL (the Open Hardware License), based 
loosely on the Open Source License, as a means 
to secure intellectual property in projects such as 
HPSDR. This will allow folks to exercise control 
over their intellectual property. They could give 
it away for anyone to use, or they could license 
it for non-commercial applications, and retain 
control of it for commercial applications of 
their own choosing. This is an overly simplistic 
explanation of a very important topic, but the 
development of the OHL will be needed to 
enable us to do other collaborations such as 
HPSDR. This too is a landmark development 
and John and TAPR are definitely breaking new 
ground, and the world is definitely watching 
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this. Everyone at the DCC was impressed by the 
effort that John has put into this, and the way 
that he has been able to develop a consensus of 
opinion among several of his legal colleagues 
who have provided comments on this and the 
developers with whom we are now working. 


John will be providing us with updates. 
I always cringe when I have to try to find 
something to share with you. I am amazed by the 


fact that I’ve had so much to share, and have to 
cut myself off and bid you all well. 


As always, we want to hear from you. Let us 
know if you think we are sailing in the right 
direction, or if you have suggestions for projects. 
I think as techies ourselves, I/We still need to 
improve our basic communication skills with 


YOU. 
73, 
Dave VE3GYQ/W8 
Spencerville, Ohio 
HHH 


Digital Voice in Hello 
ARRL Special Event 


By Mel Whitten, KOPFX 


Digital Voice operators around the world 
are invited to participate in this special event 
“Hello”... This event is celebrating the centennial 
of voice transmissions over the airwaves on 
Saturday December 29 and Sunday December 
30, 2006. Both AOR 9000 / 9800 Digital Voice 
modems and WinDRM software may be used. 
During the event, use the AOR and WinDRM 
“On-Line Finders” found at www.nIsu.com and 
enter your Call/QRG/QTH/ and information 


on your activity under Comments. 


Look for further information on this event at 
www.hamradio-dv.org and the ARD9800 and 
WinDRM reflectors. Calling frequency will 
be 14.236. Other DV frequencies are listed on 
the hamradio-dv.org and nlsu.com web pages. 
Submit your logs to KQ6EH at hamradio-dv 
for a chance to win a new AOR ARD-9800 Fast 
Radio Modem. 


HHH 
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Doug McKinney, KC3RL, Silent Key 


Former TAPR Director Doug McKinney, KC3RL, 
became a silent key on December 14, 2006. Doug 
was a graduate of the Naval Post Graduate School 
and a retired U.S. Navy Submarine Commander. 
He later pursued a career as a design engineer and 
developed his own company. 


During his years with TAPR, Doug developed a 
variety of projects for the organization including 
interface boards for the Oncore VP/UT+/GT+ 
GPS, Garmin GPS-20/GPS-25, and the DGPS 
module. He also authored the TAPR project 
developer’s guide. 

An Advanced class Amateur Radio licensee, Doug 
resided in Chandler, AZ and was 61 years old at the 
time of his death. 


HEH 


Dayton News 


TAPR has entered into an agreement with 
AMSAT to hold a joint banquet at the Air Force 
Museum on Friday evening of the Dayton 
Hamvention weekend. In the past, TAPR and 
AMSAT ate in separate banquet facilities on 
Friday evening, which forced members who 
belonged to both organizations to choose 
between banquets. Not anymore! 

HEH 


DCC News 


TAPR’s Board of Directors selected Hartford, 
CT as the site for the 2007 TAPR/ARRL Digital 
Communications Conference (DCC) and 
Chicago, IL for the 2008 DCC. 

HHH 
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TAPR Celebrates 25th Anniversary at DCC 


From The ARRL Letter 


Some 100 communication enthusiasts gathered in 
Tucson, Arizona, September 15-17 for the TAPR/ 
ARRL Digital Communications Conference (DCC). 
This conference marked the 25th anniversary of the 
formation of TAPR (Tucson Amateur Packet Radio). 

TAPR was one of the driving forces behind the 
packet radio revolution that began in the middle 1980s, 
and it continues to be at the cutting edge of Amateur 
Radio innovation. In recent years, the organization has 


moved away from its full name, Tucson Amateur Packet 


Radio Corporation, and begun to identify itself solely 


as “TAPR.” As its president David Toth, VE3GYQ, 
explained earlier this year, “We're not just about 
packet radio anymore, and we haven’t been just about 
packet radio for some time.” TAPR has broadened 

its scope into the entire arena of packet and digital 
communications. It also offers kits for experimenters. 


DCC 2006 topics included progress reports on the 
status of the Eagle Project <www.amsat.org/amsat- 
new/eagle/index.php>, the next high-altitude satellite 
planned by AMSAT-NA, as well as developments 
in softwaredefined transceivers and APRS <www. 


arrLorg/tis/info/HTML/aprs/>. During the event, 
Kenwood displayed a new 2-meter/70-cm transceiver, 
which will come on the market early next year and does 
not yet have a model number. 

TAPR has announced that Eric Ellison, AA4SW, 
and Scott Cowling, WA2DFI, have been elected as new 
members of the TAPR Board of Directors. John Koster, 
WO9IDDD, was reelected to a new term on the Board. 


HAH 


—E 


TAPR pioneers at the 25th Anniversary cake. From left to right: James Fortney, K6IYK; Pete Eaton, WB9FLW;; Bill Reed, WD0ETZ; Mel Whitten, 
KOPFX; Mike Parker, KT7D; Chuck Green, NOADI; Lyle Johnson, KK7P; Mike Baker (no call); Dan Morrison, KV7B; Fried Heyn, WAGWZO; Bob 
McGwier, N4HY; Eric Gustafson, N7CL (Photo by Mark Raptis, KF6WTN) 


TAPR PSR 
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New TAPR Board Members 


The recent TAPR election resulted in the 
election of two new board members (AA4SW and 
WA2DFI) and the reelection of one board member 
(W9DDD). Here are their brief biographies. 


Scott Cowling, WA2DFI 


Scott was first licensed in 1967 at age 14. He has 
been continuously active and on the air since then. 
He enjoys mobile CW, FD (just completed his 38th 
consecutive one), APRS, kit building, Software 
Defined Radios, and public service. He is an advisor 
for Explorer Post 599, the ham club for teens in 
the Phoenix area. He has been the president of a 
small, but successful electronics-consulting firm 
for the past 11 years. With the combination of his 
ham radio and business experience, he feels he 
can contribute to the growth, management and 
continued well-being of TAPR. 


Scott’s contact information: 
Scott Cowling, WA2DFI 
P.O. Box 26843 
Tempe, AZ 85285-6843 
email: scotty@tonks.com 


phone: 480-929-9529 (h), 480-736-8714 (w) 


Eric Ellison, AA4SW 


Eric was first licensed as a Novice in 1965, reaching 
Extra in 1969. He was very involved in the early years of 
packet, in both GRAPES and TAPR. 


He is a life member of ARRL, and a member of 
RSGB and TAPR. A true digital aficionado, Eric enjoys 
rag chewing on CW, especially 20 meters. 


Eric was an early adopter of the SDR-1000 Software 
Defined Radio, and has been an enthusiastic advocate 
for SDR users worldwide. He has been the moderator 
for the SDR forum at Dayton for the past two years. 


For two years he has also hosted the Internet 
based, Teamspeak VoIP group conferencing for the 
advancement of SDR and many other ham radio 
related topics. Teamspeak has provided private 
conferences for AMORP, AMSAT and TAPR. 


He worked for 27 years as an agricultural research 
scientist, and for the last 18 years as an IT professional. 


Eric is been married to Kathy, N4RVU, has three 
children and five grandchildren. 

Eric’s contact information: 
Eric Ellison, AA4SW 
5276 E Shore Dr 


Conyers GA 30094 
e-mail: ecellison@comcast.net 


John Koster, W9DDD 


John has been involved with amateur digital 
communications since 1959, acquiring his first 
Teletype shortly after becoming licensed. 

John contributed to the development and 
deployment of TexNet while a member of TPRS 
(Texas Packet Radio Society). 

John enjoys the RG@D/building side of the 
amateur radio hobby. He has been involved in the 
production and/or design of several TAPR kits. 
The Compact Flash Adapter, PIC-E, T-238, to name 
only a few. 

He began his involvement with TAPR in 1994 
serving as board member. He presently shares 
Office Manager duties with his wife Laura. 

John resides in Richardson, TX and is retired. 

Hitt 
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Catalog on Line 


The complete TAPR catalog is on line at https:// 
www.tapr.org/products.php there you will be able 
to join TAPR, renew your membership, buy parts, 
buy kits, buy goodies, buy books, and buy software 
that TAPR produces and/or distributes. 

Recent additions to the TAPR catalog include: 


TADD-ENG, Enclosure for the TADD series of 
kits <www.tapr.org/kits_tadd-enc.html> 

ANTIA, A version of the AN97, which is 
designed for bracket mounting rather than 
magnetic, mount <www.tapr.org/gps_antla.html> 

Atlas PCB, The backplane for the HPSDR project 
<www.tapr.org/kits_atlas.html> 

Atlas parts kit, parts to populate the Atlas 
backplane <www.tapr.org/kits_atlas.html> 

Pinocchio, the extender board for the HPSDR 
project <www.tapr.org/kits_pinocchio.html> 


The Clock Block, a flexible frequency synthesizer 
for timing applications <www.tapr.org/kits_clock- 


block. html> 
HHH 
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Clock-Block 


By John Ackermann N8UR, jra@febo.com 


Some time ago I mentioned that I was working ona clock 
synthesizer board that could be used (among other things) 
to get much better timekeeping for applications like NTP. 


The idea is to replace the motherboard crystal with a 
connection to the synthesizer, which can be programmed 
to generate the correct frequency when driven by a higher 
quality external oscillator. The end result is a PC clock that’s 
far more accurate and stable than the original crystal can. 
provide. 

I’m pleased to announce that my project worked out, 
and TAPR is now taking orders for the “ClockBlock” as a 
fully assembled unit (however, you'll still have to do some 
soldering on your motherboard to replace the crystal with 
the connection to the ClockBlock). 


We are having the first batch manufactured now, and 
hope to begin shipment within a couple of weeks. I’m 
pleased that we'll be able to offer the assembled unit for 
a price not much more than I originally thought a kit 
version would cost; the circuit uses surface mount parts that 
might be challenging for some folks to solder, so offering it 
assembled makes life easier for everyone. 


There's more information about the ClockBlock, and 
you can place an order, at www.taprorg/kits_clockblock. 
hil. 


HHH 


TADD Enclosure 


By John Ackermann, N8UR, jra@febo.com 


TAPR is pleased to announce that the TADD 


Enclosure is now available. 


It’s an attractive metal case designed to hold 
any of the TADD series boards. You can get more 
information, and place an order, at http://www. 
tapr.org/kits_tadd-enc.html (click on the small 
pictures on the web page to see larger versions). 


The TADD Enclosure costs $35 for TAPR 


members, and $39 for non-members. 
#H# 
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D-PRS 


By Pete Loveall, AE5PL, pete@ae5pl.net 


D-PRS is the acronym coined by Icom America 
for the DSTAR/APRS gateway designed by Peter 
Loveall AE5PL as an adjunct to javAPRSSrvr 
and as a stand-alone application. This white 
paper describes the Icom GPS implementation 
using the D-STAR low speed data channel, the 
APRS requirements for translation, and the 
implementation specifics of the D-PRS gateway. 


D-STAR is a digital protocol specification 
created by the JARL (the Japanese equivalent 
to the ARRL). The JARL has published the 
protocol and translated documents can be found 
online. The two key components to the DSTAR 
protocol are the high-speed data protocol, which 
is used for Ethernet encapsulation and transport 
(128 kbps), and the digital voice (DV) protocol, 
which incorporates FEC voice at 3600 bps and 
pure serial data at 1200 bps. This paper focuses 
on the data portion of the DV protocol. It is 
important to note that the DV signal is 4800 bps 
GMSK and the division between digital voice 
and serial data is fixed at 3600 bps and 1200 bps 


respectively. 


There are no restrictions in the specification 
regarding data that can be sent down the data 
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portion of the DV protocol. However, radio 
implementations have imposed their own 
restrictions, which must be considered anytime 
an author wishes to use that data channel. It is 
also important to note that the data channel has 
no inherent error detection or error correction. 
That is left to software authors to address. 
Finally, due to synchronization issues, the actual 
throughput of the data channel is less than 1000 
bps. This should also be considered. 


Icom DV Data Channel Implementation 
All Icom D-STAR radios bring the DV data 


channel out via a standard asynchronous serial 
port (3-wire RS-232 on the VHF/UHF radios, 
USB on the 1.2 GHz radio using a USB-to Serial 
driver). The restrictions on the data port in data 
mode are Xon/Xoff flow control and certain hex 
control codes for software control of the radios. 
The ID-1 uses OxFE and OxFD for control codes. 
There is no indication of source or destination 
callsign in the data stream presented to the serial 
port for received data (everyone sees everything 
with no source indication). There is no error 
detection or error correction on the serial data. 


Icom implemented a GPS position exchange 


capability in their VHF and UHF radios using 
the DV data channel. This capability was never 
intended to be as robust as APRS but rather 
to give quick tactical position reporting to the 
D-STAR radios. The implementation basically 
sends the raw GPS strings (the operator can 
select which ones) along with an ID/message 
line via the DV data channel. The ID/message 
line consists of the 8-character radio call sign, 
a comma, and the 20 character GPS message 
(message C1), which is preset by the operator 
into the radio. 


The position report can be set to send every X 
seconds or minutes, or it can be set to only send 
when transmitting voice. In either case when 
GPS is enabled, the radio sends the GPS & ID/ 
message lines continuously while transmitting 
voice (PTT depressed). Transmitting voice via 
PTT does not reset the position report timer. 


Because the GPS strings and the ID/message 
line are sent via the DV data channel, they 
appear as-is on any D-STAR serial port where the 
receiving radio is not in GPS mode. This fact is 
how D-PRS can be implemented with a D-SSTAR 
radio in standard (not GPS) mode. 
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D-STAR to APRS Translation 


The first piece of D-PRS is getting the DSTAR 
position ports reliably translated into APRS 
format for consumption by APRS clients. The 
following key issues had to be addressed: 


1. Reliable reception. 


Because the DV data channel is not reliable 
(no CRC or FEC), a standard XOR checksum 
is implemented by placing the checksum in the 
GPS (C1) message using the same format used 
for GPS strings. The GPS strings automatically 
use the XOR checksum so no change was needed 
here. 


2. Standard APRS format. 


Received position reports could consist of 
multiple GPS strings with an associated ID/ 
message field. This had to be reduced to a single 
APRS position packet dictating either a standard 
format or Mic-E. The standard APRS position 
format was chosen to reliably show position, 
course, speed, altitude, and comment in one 
packet. 


3. Symbol selection. 


A mechanism was needed to allow an Icom 
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radio user to select which APRS symbol they 
want to use. This was implemented using 
the XYZ format for GP destinations (APRS 
specification) due to the limits on character 
selections on the radio messages. 


4. Callsign-SSID creation. 


D-STAR has no callsign-SSID equivalence to 
AX.25. The Icom standard for callsign settings 
is to use the Amateur’s callsign followed by filler 
spaces and then placing a character in the eighth 
position. We replace the filler spaces with a 
single hyphen, which gives the appearance of a 
callsign-SSID with an alphanumeric SSID. This 
also dictates using APRS third-party packets for 
APRS network compatibility. 

5. D-STAR is not AX.25. 

As stated in #4, there is no relationship 
between AX.25 and D-STAR. As such, it was 
determined to use third-party packets on RF to 
denote the different networks. DSTAR™ is used 
in the third-party header to denote a packet 
received or transmitted (see later) on the D- 


STAR network. 


6. Potential flooding due to continuous 


positions during voice transmission. 


Due to the continuous transmission of 
positions while transmitting voice on DV, a 
mechanism was put in place to only pass the first 
position seen during a voice transmission. 


The protocol developed is as follows: 


1. GPS strings preceding an ID/message line 
are ignored if the entire ID/message line (29 
characters) does not pass the XOR checksum 
(start with zero). GPS strings with invalid 
checksums are ignored. 


2. $GPRMC and $GPGGA strings only are 
translated providing a single standard position, 
course, speed, altitude, comment APRS position 
packet. A space always follows the 3-digit speed 
if a message or altitude is present. The altitude 
(/A=xxxxxx) string is always at the end of the 
comment field. 

3. The APRS symbol is derived from the first 
four characters of the message line. The format is 
XYZ_ where _ is a space. XYZ are per the APRS 
specification for GPXYZ symbol definition. 

4. The 4 character symbol at the beginning 
of the message and the *CS (checksum string) 
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at the end of the message are stripped and the 
remaining 13-14 character message is space 
trimmed and placed in the comment field if 
there are non-space characters present. 


A sample APRS position gated to APRSIS is: 


KC5ZRQ-8>APJ123, DSTAR*,qAR,KC5ZR 
Q-2:!3330.35N/10150.87W>353/000 V82/ 
145.67MHZ/A=003212 


Note the DSTAR% for insertion to APRS-IS 
denoting the network the packet came from. 
There is a space between the 000 and the V82. 
The altitude field is at the end. If this packet 
were gated directly to RF via a stand-alone 
device, it would look like: 


MYGATE>APRS, PATH:}KC5ZRQ- 
8>APJI23, DSTAR*:!3330.35N/ 
10150.87W>353/000 V82/145.67MHZ/ 
A=003212 


MYGATE, APRS, and PATH in the RF header 
are set to the RF gateway’s callsign, destination, 
and path respectively. Note the encapsulation of 
the D-PRS packet in the third-party format. 

To have this APRS packet created, KC5ZROQ 
had to do the following three steps (quotes 


10 


included for clarity, they are not programmed 
into the radio): 


1. Program the radio MyCall to “KC5ZRQ 8” 


2. Program TX message C1 to “LK V82/ 
145.67MHZ*64” 


This message is automatically calculated at 
www.aprs-is.net/dprscalc.htm 


3. Program the radio to only transmit RMC 
and GGA GBPS strings. 


APRS over D-STAR 
Gating APRS packets over D-STAR is not 


too difficult but there are some considerations. 
Primary is the fact that the DV data channel has 
no error detection or correction. Second, the 
Icom implementation does not allow for pure 
binary transmission due to the xon/xoff flow 
control and the reserved command characters 
described earlier. 


The desire to gate APRS over the DSTAR DV 
data channel is found in wanting to connect 
APRS clients over the low-speed channel to 
APRS-IS or to an APRS RF network. This could 
be accomplished via two methods: emulate a 
TNC or emulate an APRS-IS server. Emulating a 
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TNC would restrict D-STAR callsigns to AX.25 
format, which is not desired. Emulating a TNC 
would also require simulating either KISS mode 
or simulating TNC commands to get MYCALL 
information (remember that the DSTAR 
protocol does not have station identification 


within the DV data channel). 


Emulating an APRS-IS server allows flexible 
callsign definition (can match how the callsign 
of a D-STAR station running in GPS mode is 
converted to APRS). It does not require any 
modification to Internet-ready APRS clients to 
function. It provides the ability to have multiple 
clients connect to a single D-STAR radio. 


To emulate an APRS-IS server, DStarTNC2 
accepts TCP/IP connections and parses the 
login line. Just like APRS-IS, the client must 
supply a valid passcode for its callsign to achieve 
bidirectional operation. A read-only passcode 
(-1) can be used to monitor received APRS 
packets. DStarTNC2 passes both APRS packets 
and D-STAR GPS position reports as APRS 
positions to the client. DStarTNC2 passes 
packets from the APRS client to the DSTAR DV 
data channel after replacing the TCPIP* in the 
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path to DSTAR’. This identifies the packet as 
originating on a D-STAR network instead of on 
APRS-IS. 


There is on more very important piece of 
the gated APRS packets: an XOR checksum 
is appended to each line before transmission 
and stripped from each line before passing to 
the APRS client. This checksum is the exact 
same format as used in GPS strings (except 
this checksum covers the entire string) and the 
D-STAR ID/message line. It is important that 
this checksum never appears on APRS-IS or in 
an APRS network, as it would materially affect 
APRS dupe checking. javAPRSSrvr can act as an 
IGate for remote APRS clients and DSSTAR GPS 


mode radios. 
Summary 


To avoid the issues seen a few years ago with 
Mic translation on APRS-IS, all authors 
must perform D-STAR to APRS translation 
uniformly. This makes the special formatting 
and interpretation of the Cl message critical. It 
also makes the translation to a standard position 
format critical to normal APRS operation. 
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APRS over D-STAR is not a translation 
process though the software that does this 
function can (and should) do the D-STAR to 
APRS translation for the APRS client. This 
is basically substituting the DSTAR DV data 
channel for AX.25. Because there is not built- 
in error correction or detection in the DV data 
channel, a checksum is added to APRS “packets” 
solely for transport over the D-STAR link. The 
checksum does not appear at the client or at the 


IGate. 
D-PRS makes the D-STAR radios very effective 


tactical radios providing single channel data and 
voice operation. This eliminates cross-channel 
issues such as front-end overloading which are 
present in systems using discrete data and voice 
channels. D-PRS brings the power of robust 
APRS applications including extensive mapping 
options to the D-STAR networks. 


HHH 
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Are the Bands Going to Hell? 


By Pete Kemp, KZ1Z, kz1z@arrl.net 


Here is your chance to operate one of the “new” digital modes that has a lot of 
history behind it. 


For the past six or seven years I’ve enjoyed the leisurely pace of Hellschreiber. 
This digital mode prints across your computer screen a bit like a fax. This is 
why Hellschreiber is sometimes dubbed the “fuzzy mode”. If you would like 
to hear what a Hellschreiber signal sounds like go to: www.101science.com/ 
101 digitalsamples/HELLSCHREIBER_SAMPLE.WAV 

Feld-Hell chugs along 
at 25 wpm, and some 
software allows you to 
print simple pictures like 


515 PROSE SENDING 


THIS 1S PROSE SENDING O hee 


aa 
smiley faces and stars. You will find operators who like to rag chew, as well as 
many DX “quickie, 5x9 Good-bye” contacts. It always amazes me when a real 


DX station pops on. One afternoon I had a ZD7, St Helena Island, call me. It is 
thrill to be on the other side of a “pile up.” 


ARich History 


There is a rich history to this mode, which was originally patented in 1929 
by Rudolf Hell. This digital system was developed for the German military. 
Hellschreiber was used extensively in portable field operations during WWII. 
This mode eventually was employed by some news services, remaining in use 
until 1980. Unlike teleprinters, Hellschreiber machines had only two moving 
parts, so were mobile and dependable. This method of transmission is also 
referred to as Field-Hell or Feld-Hell today. Hellschreiber is translated from the 


German, meaning Hell’s writer. 
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You don’t need a Hellschreiber machine from a flea market to get started. 
The combination of a computer, with sound card, software and a few wires is 
all you need to join in the fun. If you are currently using computer generated 
digital modes, such as RTTY, SSTV or PSK31, you are already capable of 
Hellschreiber. IZ8BLY, MultiPSK or commercially available MixW, may all be 


acquired via the Internet. 
Anybody Out There? 


Until recently, 
N49 44 Hellschreiber enthusiasts 
ER HADE | N19 YY were sometimes frustrated 
by the low level of activity 
in the mode. In March 2006 a Feld-Hell club was formed. In four months 
nearly 400 members have signed up. The interest has been sparked! The club 


WORLDWAR2 HELLSCHRE| B 


has stimulated a renewed interest in the old fuzzy mode. Membership is free. 
Achievement awards are available. In an interesting twist, to earn an award log 
data is sent by mail. Once verified, a serialized electronic certificate is issued. 
You print out your own award. Thus, there are no postage, processing or 
production fees. The club’s home page has links to a cluster that spot digital 
stations, a monthly club newsletter and weekly HF nets. 


You can learn about the Hellschreiber mode, join the club and get links to 
software at www.feldhellclub.co.uk/ . If you wish to join, send an e-mail to: 
join@feldhellclub.co.uk with your name, call and address. You will receive an 
FH# in a return e-mail. 

In Hellschreiber QSOs are twice as good! 


HH 
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(Some) Encryption 
By Don Rotolo, N2IRZ, n2irz@worldnet.att.net 


In the process of verifying some assertions made 
by a fellow Ham regarding the need for encryption 
on the amateur bands, I stumbled across something 
almost unbelievable: Part 97 permits some 
encryption, such as WEP on 802.11 gear. 


As incredible (literally) as that statement seems, 
I firmly believe it to be true. Conversations with a 
highly placed official at the FCC, as well as at the 
ARRL and in the HSMM working group, support 
that conclusion. I can’t mention any names, because 
anonymity was requested, but I expect to see a 
statement on the topic from some credible Hams 
any day now. 


The basic premise is that Part 97 is unusually 
vague and specific at the same time. In virtually 
every case, Part 97 discusses practice and 
performance, but in Part 97.113(a)(4) it specifically 
prohibits “... messages encrypted for the purpose 
of obscuring their meaning”. The key word here is 
purpose. 


It is extraordinarily rare for Part 97 to regulate 
purpose, not practice, and we have to assume that 
the rules were written to mean exactly what they say. 


So, if my purpose for encrypting a signal was, for 
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is Legal! 


instance, to comply with Part97.113(e) (stating 


“no station shall retransmit programs or signals 
emanating from any type of radio station other than 
an amateur station...”) because your 802.11g Gear is 
surrounded by Part 15 users, then it’s perfectly legal. 
If it so happens that to maintain that compliance 
you need to encrypt everything, well, so be it. 


There are other instances as well. Think about 
it for a while, and you will come up with other 
purposes for needing encryption that do not involve 
specifically the obfuscation of meaning (although 
that may happen to be a by-product). Some of these 
purposes can be argued - privacy is a good example 
- but others are clearer. (Note: This isn’t limited to 
802.11, it applies equally to HF, so long as you keep 
the communications within the country. Some 
international agreements prohibit encryption). 


Sure, there are caveats. You need to comply with 
97.309(a)(4), about the modulation scheme being 
publicly documented, (I’m pretty sure 802.11 and 
WEP both comply), plus you certainly have to 
ID every 10 minutes. I believe it would be good 
amateur practice to make a note of the encryption 
key in your station log, too. 
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From the FCC’s point of view, they really only 
need to know who is doing the transmitting. For 
that, I’d think setting the SSID to your callsign 
would be enough. If they also need to know what 
it is that you’re transmitting, they can just ask, or 
even easily record the signal in full bandwidth, 
and stop by later to ask for the decryption key so 
they can play it back and see what it was. Surely 
the Government can do this even without your 
assistance, but I seriously doubt anyone would 
refuse to hand over the key. 


As far as content is concerned, use the Grandma 
Test: If you wouldn’t be proud to have your 
grandma hear what you’re sending, then you 
probably shouldn’t. 


Surely this issue will be controversial, and 
although I can’t name names, | heard it with my 
own ears: Some encryption is perfectly legal under 
Part 97. If you remain doubtful - I don’t blame 
you - then wait a while and see what comes of this 
fairly recent information. For the rest of us, though, 
there’s nothing standing in your way. 


HHT 
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Digital Voice Using 100-Hz Bandwidth 


By Mike Lebo, N6IEF, mike-lebo@ieee.org 


Objective: To outline the steps needed to achieve 
digital voice using 100-Hz bandwidth with the 
intent to develop software that could be used by 
amateur radio operators. 


Overview of hardware: Voice will enter 
a computer from a microphone from the 
microphoneinput of the sound card when the 
space bar of the keyboard is held down. It will be 
processed and sent out as a Phased Shift Keying 
(PSK) audio tone from the line-output of the sound 
card to the amateur radio transmitter. Using Signal 
Side Band (SSB) modulation, the PSK audio tone 
will be converted into Radio Frequency (RF) PSK 
and sent out through an antenna. Another antenna 
and amateur radio receiver at a different location 
will receive this RF and convert the PSK RF into 
a PSK audio tone. This PSK audio tone will go 
into the line input of the sound card of the other 
computer, where it will be processed and the voice 
will be played on the computer’s speakers. This 
hardware is readily available at most ham radio 
stations. 


Steps need for the computer processing during 
transmit: 
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1. The digitized audio from the microphone will 
be compared to a list of 44 digitized audio clips 
called phonemes. While the next block of digitized 
audio from the microphone is being compared, a 
histogram of the best five matches from the first 
digitized audio will determine. The best fit from 
this histogram will be found by comparing the five 
phonemes at different speeds. 


2. Once a phoneme is identified, a unique coded 
sequence will cause a PSK audio tone to be made 
and sent from the line out of the computer sound 
card, 


Note: The rate at which the code is sent out 
will equal the rate at which the audio from the 
microphone is received, but it will be delayed by 
one-half second to allow the computer time check 
its look-up tables. 


3. If the audio level drops below a set threshold, 
a code of 111000 will be repeatedly sent until the 
amplitude of the audio goes above the threshold. 


Steps need for the computer processing during 
receive: 

1. The audio from the ham radio receiver will be 
sent to the line input of the sound card and will be 
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digitized through a process like the readily available 
PSK-31 software. A waterfall will display on the 
computer monitor and through an algorithm using 
Digital Signal Processing (DSP), a digital 100 Hz 
bandwidth filter will reduce the noise of the 2400 


Hz filter of the ham radio receiver. 


2. The PSK audio tone will be detected and 
converted into a code, which will be compared to a 
lookup table of audio clips. Since the lookup takes 
time, a one-tenth second delay will be added from 
the time the PSK audio tone is received to the time 
the audio clip comes from the speaker. 


3. The audio clip will be stretched in time and 
played on the computer speaker until the next 
audio clip is played. Note: No sound will be played 
when the code of 111000 is detected. 


Generations of the transmit phonemes: Since 
each person sounds different from another, it is 
clear that the computer must recognize the unique 
phonemes from the person operating the digital 
voice using 100 Hz bandwidth software. The 
software must be able to teach itself the phonemes. 
Once learned, the computer will recognize that 
person’s voice. 
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1. The initial phonemes setup will be done 
by having the person read words shown on the 
computer monitor and speak these words into the 
microphone of the computer. Whenever the person 
speaks into the microphone, they must hold down 
the space bar. This must be done in a very quiet 
place to eliminate background noise. 


2. Each word will be spoken three different times: 
once normally, once loudly and once quietly. This 
will accomplish two different things. First, it will 
be used to calibrate the DSP automatic speech 
compression algorithm to constantly adjust the 
microphone gain for fixed output level. I believe the 
variations of voice amplitude add very little to the 
context of speech and they will not be sent or played 
at the speaker of the ham radio receiver. Second, 
parts of these words will be used to generate the 44 
digitized audio clips called phonemes. 


3. These phonemes will be combined to form 
phrases, which will be played over the computer’s 
speakers. The person will then repeat these phrases 
into the computer’s microphone, while holding 
down the space bar. Each phrases will be spoken 
three different times as in step 2; once normally, 
once rapidly and once slowly. The initial group 
of 44 digitized audio clips will be replaced by 132 
digitized audio clips. This process will be repeated 
and averaged until the computer has all the digital 
audio clips need to always understand the person. 
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Although there are three digitized audio clips for 
each phoneme, only one code will be generated for 
that phoneme. 


The code used to send and receive the PSK tone: 
The 44 phonemes (see www.btinternet.com/~ ted. 
power/phon00.htm) will be represented by a code 
made up of l’s and 0’s. 


Most of the characters will be 1’s to offset the 
O’s that will be added to stretch the time between 
phonemes. All code groups will start with a 1 and 
end with three or more 0’s. Since phonemes are 
grouped by the shape of the mouth, the codes used 
in one group of phonemes should be as different as 
possible from other groups. Example, a “b” sounds 
like a “v” and their codes should be similar, but they 
sound much different from the sound of an “m” 
which should have a much different code. Some 
phonemes are longer then others and they should 
have a longer code. Others are short like the sound 
of the letter T, which will have a short code. There 
should never be a code with 0001 in it. When a 
code with 0001 or any other unrecognized code is 
detected at the computer of the ham radio receiver, 
an errorcorrecting algorithm will be used to take a 
best guess at what the code should have been. The 
44 of the following 51 codes will be used with seven 


as spares. 

1000 11000 101000 1001000 
1011000 1101000 1111000 10011000 
10101000 10111000 11001000 11011000 
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11101000 
101001000 
110011000 
111011000 
1001011000 
1010101000 
1011101000 
1101001000 
1110011000 
1111011000 


11111000 
101011000 
110101000 
111101000 
1001101000 
1010111000 
1011111000 
1101011000 
1110101000 
1111101000 


100101000 
101101000 
110111000 
111111000 
1001111000 
1011001000 
1100101000 
1101101000 
1110111000 
1111111000 


100111000 
101111000 
111001000 
1001001000 
1010011000 
1011011000 
1100111000 
1101111000 
1111001000 


Note: The code 111000 is a special code for no 
sound and is not used by the phonemes. 


As shown, it is the fastest speed for each phoneme. 
With a 100 Hz clock, 10 or more phonemes could 
be sent every second. Just think about moving your 
mouth to 10 different position every second. I can’t 
do it. 


By adding one or more extra 0’s to any code, 
the length of that phoneme will be stretched by 
increments of 1/100 of a second. This is very 
important because voice is contently changing in 
speed. The original set of 44 phonemes will be 
expanded to over 440 phonemes. 


Let’s show an example of how each code could be 
expanded to a very large set of new codes. The code 
1000 is the smallest, but by adding a 0 it becomes 
10000. It is the same phoneme, but stretched by 
1/100 of a second. The number of 0’s added is 
dependent on when the next phoneme is detected 
at the transmitter and that code is sent. At the 
receiver the lookup table finds the phoneme when 


TAPR PSR 


three 0’s in a row are detected. Another lookup 
table then finds the correct audio clip based on the 
number of additional 0’s. This will account for all 
variations of voice speed without extending the 100- 


Hz bandwidth. 


The 100 Hz clock: It is easy to make the 100 Hz 
clock used to send the PSK audio tone at computer 
of the ham radio transmitter. But at the computer 
of the ham radio receiver, a new 100-Hz clock must 
be made by synchronizing the new clock to six times 
the frequency of the special code 111000. A very 
narrow band digital filter will detect that unique 
frequency with very little noise. If the space bar were 
pressed just before speaking into the microphone, 
this special code would be sent. 


The receiver phonemes: Since each person has 
a unique set of phonemes, there is no way for the 
computer at the ham radio receiver to know how 
the make received code sound. This is the normal 
case for ham radio transmissions. So to make 
this more fun, 12 different sets of audio clips will 
be available by selecting F1 through F12 on the 
keyboard. These will be from the sound of a little 
girl, to that of an old man and anything in-between. 


Improvements that could be made after the 
system is working: One of the problems in selecting 
the code for the transmit phonemes is the error 
contributed by the background noise picked up 
by the microphone. To reduce this noise, two 


16 


microphones should be used, one with the person’s 
voice plus the background noise and the other with 
just the background noise. The computer could 
easily subtract the background noise. Computer 
sound cards are equipped for stereo, so that should 
be no problem. 


The computer at the ham radio transmitter will 
learn exactly what the phonemes are for the person 
sending the transmission. This set of phonemes and 
the sending station’s call sign could be emailed to 
the digital voice using 100- Hz bandwidth software 
at receiver's computer. When the computer at the 
ham radio receiver detects the code for the phrase 
“This is (followed by the transmitting call sign)”, 
it will automatically switch to the e-mailed set of 
phonemes for that call sign. That way the sound 
from the speaker of the computer at the ham radio 
receiver will sound like the voice of the person 
doing the transmitting. This would be useful for 
three-way conversations or nets. 


Implementation of the system: Since this could 
be used all over the world, the software must be 
available on-line. 


HAE 
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